Add HeyBoxChat to the list of supported providers #2374

gehongyan · 2025-08-20T10:03:39Z

This pull request would like to add HeyBoxChat to the list of supported providers.

Signed-off-by: Gehongyan <[email protected]>

gehongyan · 2025-08-20T10:24:27Z

Docs

OAuth: https://s.apifox.cn/43256fe4-9a8c-4f22-949a-74a3f8b431f5/7145802m0
Auth Page: https://s.apifox.cn/43256fe4-9a8c-4f22-949a-74a3f8b431f5/329051392e0
Token Request: https://s.apifox.cn/43256fe4-9a8c-4f22-949a-74a3f8b431f5/329070402e0
User Info Request: https://s.apifox.cn/43256fe4-9a8c-4f22-949a-74a3f8b431f5/329599863e0
Token Refresh Request: https://s.apifox.cn/43256fe4-9a8c-4f22-949a-74a3f8b431f5/329079907e0

Hints

HeyBoxChat is a product similar to Discord, and its API provides bot-like capabilities.
HeyBoxChat currently hosts its documentation on Apifox, a product similar to Postman.
The user authorization page does not have a "Deny" button.
The token request requires additional query parameters to declare to their gateway that the requests are coming from a bot, rather than from their own client or web product carrying user login information. Although the documentation does not explicitly state this, it is the case in practice.
The token request requires the bot token to be included in the request headers.
In the response body of user info requests, the user information is wrapped in the "result" field.

Note

Question 1: Of the 7 additional query parameters that need to be passed, "chat_version" may change as their product updates, while the other fields remain the same for requests coming from a Bot. Do we need to introduce a setting for "chat_version"?

Useful Screenshots (Machine translated from Chinese)

Bot development platform

Here is the bot token.
Auth page.
Console demo.

kevinchalet · 2025-08-20T10:56:33Z

Thanks for your PR! ❤️

Token requests and user info requests require additional query parameters to declare to their gateway that the requests are coming from a bot, rather than from their own client or web product carrying user login information. Although the documentation does not explicitly state this, it is the case in practice.

👍🏻
AFAICT, you added the code necessary to add these query string parameters to the token request but not the userinfo request. Is it deliberate?

Question 1: Of the 7 additional query parameters that need to be passed, "chat_version" may change as their product updates, while the other fields remain the same for requests coming from a Bot. Do we need to introduce a setting for "chat_version"?

Hum, good question. If that "chat version" thing is like an API version, we usually don't expose that as a setting: instead, it's purely an internal thing we update when the schema changes and requires changing something in our implementation.

FYI: I see you blurred the oi_reg_id claim in your screenshot: unless you explicitly set it to a specific value, it's just a SHA256 hash of the issuer URI and provider name (if present). In this case both values are known and public so no point wasting too much time hiding it:

openiddict-core/src/OpenIddict.Client/OpenIddictClientConfiguration.cs

Lines 309 to 341 in 4902658

    
           static string ComputeDefaultRegistrationId(OpenIddictClientRegistration registration) 
        
           { 
        
               Debug.Assert(registration.Issuer is { IsAbsoluteUri: true }, SR.GetResourceString(SR.ID4013)); 
        
               using var algorithm = CreateAlgorithm(); 
        
               TransformBlock(algorithm, registration.Issuer.AbsoluteUri); 
        
               if (!string.IsNullOrEmpty(registration.ProviderName)) 
        
               { 
        
                   TransformBlock(algorithm, registration.ProviderName); 
        
               } 
        
               algorithm.TransformFinalBlock([], 0, 0); 
        
               return Base64UrlEncoder.Encode(algorithm.Hash); 
        
               [UnconditionalSuppressMessage("Trimming", "IL2026", 
        
                   Justification = "The default implementation is always used when no custom algorithm was registered.")] 
        
               static SHA256 CreateAlgorithm() => CryptoConfig.CreateFromName("OpenIddict SHA-256 Cryptographic Provider") switch 
        
               { 
        
                   SHA256 result => result, 
        
                   null => SHA256.Create(), 
        
                   var result => throw new CryptographicException(SR.FormatID0351(result.GetType().FullName)) 
        
               }; 
        
               [MethodImpl(MethodImplOptions.AggressiveInlining)] 
        
               static void TransformBlock(HashAlgorithm algorithm, string input) 
        
               { 
        
                   var buffer = Encoding.UTF8.GetBytes(input); 
        
                   algorithm.TransformBlock(buffer, 0, buffer.Length, outputBuffer: null, outputOffset: 0); 
        
               } 
        
           }

😃

gehongyan · 2025-08-20T11:41:13Z

Is it deliberate?

The user info API indeed does not require those parameters now; only the token API does.

Only the token API requires those query parameters. I also want to push for them to remove all these query parameters. If there are any optimizations, I think I will update them here as well.

It seems that the user info API does not require a bot token anymore.

it's purely an internal thing we update when the schema changes and requires changing something in our implementation.

Copy that!

both values are known and public so no point wasting too much time hiding it

Many thanks! ❤️

Signed-off-by: Gehongyan <[email protected]>

gehongyan · 2025-08-21T07:44:09Z

I have received news from their development team that one day those query parameters will no longer be required, but it is still uncertain when this change will happen. When they update it, they will inform me, and I will also update it here.

kevinchalet · 2025-08-21T08:59:05Z

Many thanks! ❤️

My pleasure! ❤️

I have received news from their development team that one day those query parameters will no longer be required, but it is still uncertain when this change will happen. When they update it, they will inform me, and I will also update it here.

👍🏻

Do you think we can ship this provider as-is (or maybe with the parameters added to the userinfo request, just in case) or do you prefer waiting until they change their implementation?

7.1.0 is around the corner, so if you prefer the first option, it may ship quickly 😃

gehongyan · 2025-08-21T12:15:02Z

7.1.0 is around the corner, so if you prefer the first option, it may ship quickly

Sounds great! I will make another pull request to update the code if they make any further changes.

Signed-off-by: Gehongyan <[email protected]>

gehongyan · 2025-08-22T08:08:32Z

Now, only chat_os_type is required in the query string. chat_version is optional, but keeping the version control working may be a good choice.

kevinchalet · 2025-08-22T13:30:11Z

Now, only chat_os_type is required in the query string. chat_version is optional, but keeping the version control working may be a good choice.

Should we also add these parameters to the userinfo request, tho' you said they are not currently required in practice? Just in case, you know 😄

kevinchalet · 2025-08-22T15:51:49Z

Regarding the name, do we know what the official casing is?

A quick search on Google doesn't return a lot of results (I guess the Chinese name is a lot more popular?), but "Heybox Chat" seems to be the most common result.

If it's the correct casing, we should probably name the provider HeyboxChat and add a DisplayName="Heybox Chat" attribute so Heybox Chat is used in all the documentation code.

gehongyan · 2025-08-22T17:36:39Z

Should we also add these parameters to the userinfo request, tho' you said they are not currently required in practice? Just in case, you know 😄

I confirmed with the official development team earlier today that the /chatroom/api/* information retrieval endpoints only require a bearer token if a bearer token has been obtained.

Regarding the name, do we know what the official casing is?

Before I opened this pull request, I had asked them what English names they prefer. The answer was that they do not have an official English name, and HeyBoxChat should be okay. However, the HeyBoxChat is a derivative product of HEYBOX, which is written with all uppercase letters.

HEYBOX: 小黑盒 (xiao hei he), means a little black box if translated directly.
HeyBoxChat: 黑盒语音 (hei he yu yin), means black box voice if translated directly.

About the parameter necessities and official English names, I will communicate with the development and operations teams tomorrow for confirmation.

If you need to release a new version as soon as possible, it is okay to postpone completing this pull request, since it is not urgent.

gehongyan · 2025-09-01T15:06:30Z

Should we also add these parameters to the userinfo request

They have confirmed that the userinfo API does not require those parameters. This API is located under the /api request path, and APIs under this path will not be reused with requests from the HeyBoxChat client and web with user login info. Therefore, there is no need to differentiate the source, and those parameters are not needed.

Regarding the name, do we know what the official casing is?

They have confirmed the name HeyBoxChat, rather than other spellings or variations in capitalization. Based on their reply, this should be regarded as a proper noun as a whole.

Based on the above, it seems that there is currently no code that needs further modification. Of course, if you have any ideas or hold certain opinions, I am also happy to listen to and respect them. 😄

kevinchalet · 2025-09-01T16:55:37Z

Therefore, there is no need to differentiate the source, and those parameters are not needed.

👍🏻

They have confirmed the name HeyBoxChat, rather than other spellings or variations in capitalization. Based on their reply, this should be regarded as a proper noun as a whole.

Perfect! Thanks for taking the time to deal with that! It's nice to see they positively replied to your demand 😄

Based on the above, it seems that there is currently no code that needs further modification. Of course, if you have any ideas or hold certain opinions, I am also happy to listen to and respect them. 😄

Great, let's merge it then! ❤️

kevinchalet · 2025-09-01T16:56:12Z

Merged, thanks a lot for this great contribution! 👏🏻

kevinchalet · 2025-09-10T20:15:44Z

Hey @gehongyan,

FYI, 7.1.0 just shipped with your new provider: https://github.com/openiddict/openiddict-core/releases/tag/7.1.0 🎉

Add HeyBoxChat to the list of supported providers

080f9e6

Signed-off-by: Gehongyan <[email protected]>

HeyBoxChat user info API does not require token header

392ab99

Signed-off-by: Gehongyan <[email protected]>

gehongyan marked this pull request as ready for review August 21, 2025 12:15

Removed unnecessary parameters for HeyBoxChat

72a6bf3

Signed-off-by: Gehongyan <[email protected]>

kevinchalet self-assigned this Sep 1, 2025

kevinchalet added web providers community contribution labels Sep 1, 2025

kevinchalet added this to the 7.1.0 milestone Sep 1, 2025

kevinchalet merged commit 9385b24 into openiddict:dev Sep 1, 2025
6 checks passed

Uh oh!

Add HeyBoxChat to the list of supported providers #2374

Add HeyBoxChat to the list of supported providers #2374

Uh oh!

Conversation

gehongyan commented Aug 20, 2025

Uh oh!

gehongyan commented Aug 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Docs

Hints

Useful Screenshots (Machine translated from Chinese)

Uh oh!

kevinchalet commented Aug 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gehongyan commented Aug 20, 2025

Uh oh!

gehongyan commented Aug 21, 2025

Uh oh!

kevinchalet commented Aug 21, 2025

Uh oh!

gehongyan commented Aug 21, 2025

Uh oh!

gehongyan commented Aug 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kevinchalet commented Aug 22, 2025

Uh oh!

kevinchalet commented Aug 22, 2025

Uh oh!

gehongyan commented Aug 22, 2025

Uh oh!

gehongyan commented Sep 1, 2025

Uh oh!

kevinchalet commented Sep 1, 2025

Uh oh!

Uh oh!

kevinchalet commented Sep 1, 2025

Uh oh!

kevinchalet commented Sep 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

gehongyan commented Aug 20, 2025 •

edited

Loading

kevinchalet commented Aug 20, 2025 •

edited

Loading

gehongyan commented Aug 22, 2025 •

edited

Loading